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PREFACE 


This  adainistrator 's  aanual  oovers  the  work  perforaed  under 
Air  Force  Contract  F33615-80-C-5155  (ICAM  Project  6201).  This 
contract  is  sponsored  by  the  Materials  Laboratory,  Air  Force 
Systeas  Coaaand,  Wright -Pat ter son  Air  Force  Base,  Ohio.  It  was 
adainistered  under  the  technical  direction  of  Mr.  Gerald  C. 
Shuaaker.  ICAM  Prograa  Manager,  Manufacturing  Technology 
Division,  through  Project  Manager,  Mr.  David  Judson.  The  Priae 
Contractor  was  Production  Resources  Consulting  of  the  General 
Electric  Coapany.  Schenectady,  Mew  York,  under  the  direction  of 
Mr.  Alan  Rubenstein.  The  General  Electric  Project  Manager  was 
Mr.  Myron  Hurlbut  of  Industrial  Autoaation  Systeas  Departaent, 
Albany,  Mew  York. 


Certain  work  aiaed  at  iaprovlng  Test  Bed  Technology  has 
been  perforaed  by  other  contracts  with  Projeot  6201  perforaing 
integrating  functions.  This  work  consisted  of  enhanoeaents  to 
Test  Bed  software  and  establishment  and  operation  of  Test  Bed 
hardware  and  conauni oat ions  for  developers  and  other  users. 
Docuaen tat 1 on  relating  to  the  Test  Bed  froa  all  of  these 
contractors  and  projects  have  been  integrated  under  Projeot  6201 


for  publication  and  treataent  as  an  integrated  set  of  doouaentB. 
The  particular  contributors  to  eaoh  document  are  noted  on  the 
Report  Docuaentation  Page  (DD147S).  A  listing  and  description 
of  the  entire  project  docuaentation  systea  and  how  they  are 
related  is  contained  in  doouaent  FTR620 100001 ,  Projeot  Overview. 


The  subcontractors  and  their  contributing  activities  were 
as  follows: 


TASK  4.2 

Subcontractors 

Boeing  Military  Aircraft 
Coapany  (BMAC) 

D.  Appleton  Coapany 
(DAOOM) 


General  Dynaaios/ 
Ft.  Worth 


Role 

Reviewer 


Responsible  for  IDEF  support, 
state-of-the-art  1 i terature 
search 

Responsible  for  factory  view 
funotion  and  inforaatlon 

aodels 


ill 
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Subcontractors 


Illinois  Institute  of 
Technology 


North  American  Rockwell 


Role 

Responsible  for  factory  view 
fnnotion  research  (IITRI) 
and  information  models  of 
small  and  medium-slse  business 

Reviewer 


Northrop  Corporation 


Pritsker  and  Associates 
SofTeoh 


Responsible  for  factory  view 
function  and  information 
models 

Responsible  for  IDEF2  support 
Responsible  for  IDBFO  support 


TASKS  4.8  -  4.9  (TROT  BID) 


Subcontractors 


Role 


Boeing  Military  Aircraft 
Company  (SMAC) 


Responsible  for  consultation  on 
applications  of  the  technology 
and  on  IBM  oomputer  technology. 


Computer  Technology 
Associates  (CTA) 


Assisted  in  the  areas  of 
communications  systems,  system 
design  and  integration 
methodology,  and  design  of  the 
Network  Transaction  Manager. 


Control  Data  Corporation 
(CDC) 


Responsible  for  the  Common  Data 
Model  (CDM)  Implementation  and 
part  of  the  CDM  design  (shared 
with  DAOOM) . 


D.  Appleton  Company 
(DAOOM) 


Responsible  for  the  overall  CDM 
Subsystem  design  integration 
and  test  plan,  as  well  as  part 
of  the  design  of  the  CDM 
(shared  with  CDC).  DAOOM  also 
developed  the  Integration 
Methodology  and  did  the  schema 
mappings  for  the  Application 
Subsystems . 
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Subcontractors 

Digital  Equipment 
Corporation  (DEC) 


McDonnell  Douglas 
Autonation  Company 
(MoAuto) 


On-Line  Software 
International  (OSI) 


Role 

Consulting  and  support  of  the 
performance  testing  and  on  DEC 
software  and  computer  systems 
operation. 

Responsible  for  the  support  and 
enhancements  to  the  Hetwork 
Transaction  Manager  Subsystem 
during  1984/1985  period. 

Responsible  for  programming  the 
Communications  Subsystem  on  the 
IBM  and  for  consulting  on  the 
IBM. 


Rath  and  Strong  Systems 
Products  (RSSP)  (In  1985 
became  McCormack  V  Dodge) 


SofTech ,  Inc . 


Software  Performance 
Engineering  (SPE) 


Structural  Dynamics 
Research  Corporation 
(SDRC) 


Responsible  for  assistance  in 
the  implementation  and  use  of 
the  MRP  II  package  (PIOS)  that 
they  supplied. 

Responsible  for  the  design  and 
implementation  of  the  Network 
Transaction  Manager  (HTM)  in 
1981/1984  period. 

Responsible  for  directing  the 
work  on  performance  evaluation 
and  analysis. 

Responsible  for  the  User 
Interface  and  Virtual  Terminal 
Interface  Subsystems. 


Other  prime  contractors  under  other  projects  who  have 
contributed  to  Test  Bed  Technology,  their  contributing 
activities  and  responsible  projects  are  as  follows: 


Contractors 


I CAM  Project  Contributing  Activities 


Boeing  Military 
Aircraft  Coapany 
(BMAC) 


1701 ,  2201 ,  Enhancements  for  IBM 
2202  node  use.  Technology 

Transfer  to  Integrated 
Sheet  Metal  Center 
(XSMC) 
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Contractors 

I CAM  Project 

Contributing  Activities 

Control  Data 
Corporation  (GDC) 

1502,  1701 

IISS  enhancements  to 
Coaaon  Data  Model 
Processor  (CDMP) 

D.  Appleton  Company 
(DACOM) 

1502 

IISS  enhancements  to 
Integration  Methodology 

General  Eleetric 

1502 

Operation  of  the  Test 
Bed  and  oommuni cat ions 
equipment . 

Hughes  Aircraft 

Conpany  (HAC) 

1701 

Test  Bed  enhancements 

Structural  Dynanios 
Research  Corporation 
(SDRC) 

1502,  1701, 
1705 

IISS  enhancements  to 
User  Interface/ Virtual 
Terminal  Interface 
(UI/VTI) 

Systran 

1502 

Test  Bed  enhancements . 
Operation  of  Test  Bed. 

vi 
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SECT10W  1 
INTRODUCTION 


The  SCM  administrative  functions  are  a  set  of  automated 
procedures  to  he  used  when  appropriate  by  the  SCM  administrator . 
The  SCM  adainistrator  uses  aany  VAX  and  IS/Vorkbench  functions 
aanually  to  accoaplish  various  restructuring  tasks  such  as 
aoving  files,  creating  new  directories,  deleting  libraries,  and 
so  forth.  The  autoaated  procedures  are  available  to  handle 
large  tasks  such  as  creating  a  release. 

This  docuaent  is  divided  into  five  aore  sections: 

-  Section  2  gives  a  general  description  of  SCM, 
including  specific  inforaation  on  all  SCM  directories. 

-  Section  3  provides  inforaation  on  updating  the  SCM 
database  file,  which  contains  records  on  all  IISS 
files. 

-  Section  4  provides  general  inforaation  and  specific 
directions  for  all  stages  of  the  creation  of  a  VAX 
release,  excluding  the  directions  for  testing  the 
release. 

-  Section  5  provides  the  above  inforaation  for  an  IBM 
release. 

Section  6  describes  the  aost  commonly  used  aanual 
procedures . 
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SECTION  2 

GENERAL  DESCRIPTION  OF  SCH 


2. 1  Scope 

IISS  Software  Configuration  Management  (SCM)  has  the 
following  functions: 

Storing  current  source  code  while  preserving  the 
history  of  changes  to  it. 

-  Controlling  changes  to  source  code. 

-  Facilitating  releases  with  automated  functions. 


The  SCM  system  consists  of  Source  Code  Control  System 
(SCCS),  some  DCL  (Digital  Command  Language)  code  created  by 
General  Electric,  and  one  C  program  used  to  interface  between 
the  DCL  and  SCCS.  SCCS,  a  product  of  Interactive  Systems, 
provides  low-level  functions  for  the  storage  and  changing  of 
source  code.  The  SCCS  functions  are  never  seen  by  the  general 
users  of  SCM;  access  to  the  functions  is  through  the 
relatively  user-friendly  DCL  functions. 

2.2  Directory  Structure 

The  directories  used  for  SCM  are  [SUSS],  [NIISS] ,  [IISS], 
[IISSIBM],  [CMDB] ,  [IISSCM],  and  [TIISS] .  The  directory 
structure  in  all  of  these  except  [IISSCM]  and  [CMDB]  is 
similar;  under  the  top  directory  are  the  subsystems,  and  one 
level  below  that  are  the  subdirectories.  The  following  gives 
brief  descriptions  of  the  functions  of  these  areas: 

[SUSS]  is  where  almost  all  source  code  is  stored. 

The  storage  of  the  source  code  is  controlled  by  SCCS. 
Each  source  code  file  is  given  a  prefix  SX  and  is 
stored  in  a  fora  that  separately  preserves  all  changes 
to  the  original  file.  Within  an  SCCS  file,  changes 
for  a  given  release  have  a  corresponding  SCCS  internal 
number  (6  for  Release  1.6,  10  for  Release  2.0,  15  for 
Release  2.5.  etc.).  The  files  are  created  with  the 
SCCS  "admin"  command  and  changed  with  the  SCCS  "delta" 
command,  and  any  change  level  of  the  file  can  be 
printed  into  a  file  with  the  SCCS  "get"  command.  Due 
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to  the  possible  duplicate  naaes  of  host -dependent 
code,  there  are  separate  directories  (.VAX  and  .IBM) 
under  all  directories  for  storing  the  host -dependent 
code.  These  directories  are  only  used  in  [SUSS]; 
during  releases,  the  code  for  the  proper  host  is 
pulled  into  the  saae  directory  as  generic  oode. 

[MUSS]  is  where  any  souroe  code  is  stored  that  cannot 
be  put  into  SCCS .  At  one  tiae  it  was  used  to  store 
PLI  object  files,  but  is  now  used  only  for  . FDL  (Fores 
Definition  Language)  and  .MSG  (aessage)  files. 

[ IISS]  is  the  VAX  release  directory.  Prior  to  a 
release,  aost  of  its  directories  are  cleared  out  so 
that  the  current  souroe  can  be  brought  into  it  froa 
[SUSS]  for  coapilation  and  linking.  [IISS.GOM]  is 
where  the  VAX  release  procedures  are  located. 

[IISS. BUILD]  is  the  location  of  the  .COM  files  that 
are  used  to  build  the  release  on  a  VAX. 

[ IISSIBM]  is  the  IBM  release  directory.  It  serves  the 
saae  function  as  [IISS]  except  that  it  is  for  IBM 
releases.  [IISSIBM. COM]  is  where  the  IBM  release 
procedures  are  located.  [IISSIBM. BUILD]  is  the 
location  of  the  JCL  files  that  are  used  to  build  the 
release  on  the  IBM.  Soae  of  the  JCL  files  are 
peraanent,  but  the  CL...  and  the  LK. . .  files  Bust  be 
created  for  each  release  to  provide  the  JCL  needed  to 
conpile  and  link  on  the  IBM. 

[CMDB]  is  the  SCM  database  directory.  It  contains 
Cl. DAT,  the  indexed  sequential  file  containing 
inforaation  on  all  souroe  oode.  The  aocuracy  of 
Cl. DAT  is  very  inportant  since  it  oontrols  which  code 
goes  where  into  releases.  [CMDB]  contains 
NEVITEM.DAT.  listing  all  new  files  that  need  to  go 
into  Cl. DAT.  and  RETURH.DAT,  listing  all  files  that 
were  changed  since  the  previous  release.  It  also 
contains  various  cross-reference  and  data  files  used 
for  the  SCM  user  functions.  Directories  under  CMDB 
are  used  to  store  inforaation  used  for  particular 
releases.  For  exaaple,  [CMDB.REL018]  oontains  the 
ooaaand  files  created  for  release  1.8,  and 
[CMDB.SXREL016]  contains  SCCS  souroe  files  that  were 
deleted  froa  SCM  around  the  tiae  of  release  1.8. 

These  release-specific  directories  are  stored  on  disk 
for  a  oouple  of  releases  and  then  are  aoved  to  tape 
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and  archived. 

[IXSSCM]  is  the  production  directory  for  the  CM  user 
functions,  such  as  NEWXTEM  and  CHECKOUT . 

-  [TIISS]  is  the  test  directory  for  releases.  All 

executables,  command  files,  data  files,  message  files, 
and  forms  files  are  moved  to  this  directory  (mostly  to 
[TIISS .TESTXX] )  for  Integration  testing  and  debugging 
of  a  release.  Upon  completion  of  the  testing, 
appropriate  code  is  moved  to  the  production  directory 
[PUSS]  and  the  development  directory  [DIISS] . 

2.3  SCM  Administrator  Functions 

The  SCM  Administrator  is  responsible  for  maintaining  all 
SCM  code,  including  both  user  functions  and  administrative 
functions.  The  administrator  is  also  responsible  for  running 
administrative  functions,  both  for  updating  the  8CM  database 
and  creating  releases.  The  database  is  always  updated  at  the 
beginning  of  each  release  with  all  newi terns,  but  throughout  a 
release  new  files  may  be  added.  At  any  time  file  attributes 
(e.g.  host,  subdirectory,  or  link  parameters)  may  be  changed, 
or  obsolete  files  nay  need  to  be  deleted.  When  files  are 
deleted  or  when  certain  file  attributes  are  changed,  the  souroe 
file  under  [SUSS]  must  be  moved.  This  moving  is  done 
automatically  by  the  Cl. OAT  update  program  (UPDCI.00M) ,  which 
must  be  executed  while  logged  onto  [SUSS],  due  to  the 
protections  under  [SIXS8]. 

2.4  Summary 

The  SCM  functions  provide  a  relatively  user-friendly 
interface  to  SCCS  code,  provide  the  desired  protections  and 
functionalities,  and  provide  nuoh  automation  of  release 
procedures.  Functionalities  provided  include  the  ability  to 
use  SCM  across  disks,  across  different  UIC  groups,  and  from 
directories  lacking  world  acoess.  In  order  to  provide  the 
latter  two  functions,  it  was  neoessary  to  use  the  VAX  Install 
utility  to  permanently  install  the  SOCS  interface  executable 
( IMTER.EXE)  with  DETACH  and  STSHAM  privileges  and  to 
permanently  install  the  SCCS  executables  DELTA.EXE  and 
ADMIN . EXE  with  SYSPRV  privilege. 

The  SCM  user  functions  are  described  separately  in  the  SCM 
User's  Manual,  CMU620124001 .  The  administrative  functions  are 
described  in  the  following  seotions. 


2-3 


CMA6201 24000 
1  loveaber  1985 


SBCTIOM  8 

UPDATING  THE  8GM  DATABASE 


3.1  General  Description 

The  aost  iaportant  file  in  SCM  is  one  that  keeps  track  of 
all  current  files  that  are  part  of  IISS.  This  database  file 
aust  be  updated  when  any  file  is  added  to  the  systen  or  deleted 
froa  the  systea  or  when  any  file  has  various  inforaation  for  it 
changed.  The  database  file  is  Cl. DAT.  an  indexed  sequential 
file  with  each  record  providing  attribute  fields  for  a  given 
file.  These  attribute  fields  provide  the  inforaation  needed 
during  a  release  so  that  the  file  will  be  aoved  to  the  proper 
directory,  so  that  the  file  will  be  coup i led  and  linked  as 
needed,  and  so  that  the  object  file  will  be  put  into  the  proper 
library.  The  Cl .DAT  file  is  oopied  at  the  end  of  each  release 
and  is  provided  to  all  developers  as  a  reference.  The 
alphabetical  and  sorted  versions  are  Suppleaent  1  and 
Suppleaent  2  to  the  SCM  User's  Manual,  CMU620 124001 .  The  fields 
in  the  file  are  the  following: 

-  file  (8  characters,  although  7  characters  is  the 
aaxiaua  allowable  filenaae  length) 

-  extension  (3  characters) 

-  host  (1  character) 

-  subsystea  (5  characters) 

-  subdirectory  (10  characters) 

-  docuaentat i on  group  (10  characters) 

-  coaaon  object  library  (7  characters) 
link  coaaand  file  (12  characters) 
linking  parameters  (40  characters) 

The  pr Inary  key  for  the  Cl. DAT  file  is  the  file  and 
extension.  Therefore  these  two  fields  cannot  be  altered  in  a 
given  record.  If  either  file  or  extension  need  to  be  changed 
for  a  given  file,  the  file  aust  be  deleted  froa  SCM  and  then 
newiteaed  with  the  new  naae.  The  alternate  key  is  file. 
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extension,  and  host.  This  alternate  key  is  used  for  accessing 
a  unique  record,  and  duplicate  entries  are  not  allowed. 

The  two  functions  that  are  used  to  update  Cl. DAT  are 
UPDCI.00M  and  CVTMEV . COM .  PPDCI  is  used  to  alter  a  given  file 
record  or  to  delete  it.  CVTMEV  is  used  to  add  new  files  that 
have  been  new i tewed  to  the  database. 

UPDCI  pronpts  repeatedly  for  a  filename  (FILE. EXT)  and 
allows  for  either  updating  the  file  or  deleting  it.  Pressing 
< RETURN >  at  the  filename  prompt  exits  the  program.  If  the 
administrator  is  updating  a  record,  he  is  prompted  for  the 
changes  to  each  field.  Pressing  < RETURN >  at  any  prompt  keeps 
that  field  unchanged.  If  any  fields  are  changed  so  that  the 
[SUSS]  file  must  be  moved  (such  as  subdirectory  or  host),  that 
move  takes  place  automatically.  If  any  records  are  deleted, 
the  [SUSS]  file  is  moved  to  an  obsolete  file  looation  under 
[GMDB] ,  so  that  the  name  can  be  reused  if  desired.  Beoause  of 
the  [SUSS]  file  moves,  it  is  necessary  to  be  logged  onto 
[SUSS]  to  run  the  UPDCI  oommand  file. 

CVTMEV  is  called  automatically  by  VSTART.COM  at  the 
beginning  of  a  release.  It  converts  the  newitems  in 
MEVITEM.DAT  that  are  not  designated  for  future  releases  into 
the  correct  format  for  being  added  to  Cl. DAT  and  then  adds 
them.  The  files  in  MEVITEM.DAT  that  are  designated  for  future 
releases  remain  in  the  MEVITEM.DAT  file.  CVTMEV  can  be  invoked 
separately  for  adding  any  additional  newitems  that  are  added 
during  a  release.  It  is  called  with  one  parameter  designating 
the  ourrent  release  (6  for  Release  1.6,  10  for  Release  2.0,  15 
for  Release  2.5,  etc.). 

3.2  Steps  to  Use  UPDCI 

1.  Log  onto  [SUSS] 

2.  Set  your  default  to  [IISS.COM] 

3 .  S  ©UPDCI 

4.  Enter  FILE. EXTENSION  and  HOST  at  the  prompts 

5.  View  the  file  information 

6.  Answer  whether  you  want  to  update  the  file  information 
(default  is  NO) 
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7.  If  (6)  is  NO,  answer  whether  you  want  to  delete  the 
file  (default  is  NO) 

8.  If  (6)  is  YES,  type  in  answers  to  the  fields  you  want 
changed.  Pressing  « RETURN »  at  any  prompt  keeps  that 
field  unchanged.  If  you  want  the  field  changed  to  a 
blank  field,  type  in  BLANK. 

9.  The  file  will  then  be  updated  and  you  will  be  prompted 
for  another  file  and  extension.  Press  < RETURN >  when 
you  have  finished  updating  files  and  wish  to  exit  the 
program. 

3.3  Steps  to  Use  CVTKEV 

1.  Log  ohto  [IISS] 

2.  Since  CVTHEV  will  delete  the  most  recent  version  of 
NEWITEM.DAT,  you  should  save  it  in  the  release 
directory  by: 

$  copy  [CMDBjfile. extension  [CMDB.RELOxx] * 

where  xx  is  the  two  digits  in  the  release  number  (18 
for  Release  1.8). 

3.  Set  your  default  to  [IISS.COM] 

4.  $  CVTNEW  y 

where  y  is  the  SCCS  internal  number  that  corresponds 
with  the  release  number  (6  for  Release  1.6,  10  for 
Release  2.0,  15  for  Release  2.5,  etc.). 

5.  Check  the  file  which  will  automatically  be  sent  to  the 
printer.  This  file  lists  any  exceptions  that  could 
not  be  added  to  Cl. DAT. 
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SECTIOM  4 

VAX  RELEASE  PROCEDURES 


4.1  General  Description 

A  release  is  a  step-by-step  sequential  procedure  that  vast 
be  checked  at  each  stage  to  assure  that  there  are  no  probleas. 
The  release  account,  where  the  VAX  release  is  done,  is  IISS. 

The  order  that  subsysteas  are  released  is:  (l)IPC,  (2)ERRL0G. 
(3)MTM,  (4)G0MM,  (5)UI,  and  (6)CDM.  A  VAX  release  includes  the 
following: 

-  The  Cl. DAT  file  is  updated  with  the  addition  of  all 
new  files  (newiteas),  the  deletion  of  all  obsolete 
files,  and  the  changing  of  any  Cl. DAT  inforaation  as 
needed. 

-  The  Cl. DAT  file  is  sorted  by  subsystea  and 
subdirectory  in  order  to  build  ooaaaad  files  for  the 
release. 

-  Coaaand  files  for  the  release  are  built,  one  subsystea 
at  a  tine. 

-  IISS  directories  are  eaptied  and  enpty  object 
libraries  are  created. 

-  Souroe  code  is  aoved  into  IISS. 

-  All  ooapiles.  library  replaoes,  and  links  are  done, 
one  subsystea  at  a  tine. 

-  Foras  are  created. 

-  The  files  needed  for  running  IISS  are  aoved  to 
[TIISS],  the  test  directory. 

-  The  testing  procedure  includes  doing  preooapiles  and 
aoving  the  resultant  COBOL  files  to  IISS.  These  files 
and  the  ooaaaad  files  created  to  ooapile  and  link  then 
bee one  part  of  the  release. 

-  When  testing  is  ooaplete,  the  ooaaaad  files  needed  to 
build  a  release  are  aoved  to  the  [IISS. BUILD] 
directory  and  release  tapes  are  node. 
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These  general  steps  are  normally  repeated  many  tiaes.  at 
least  partially,  for  a  release.  Vhen  a  problem  is  encountered , 
the  steps  must  either  be  repeated  or  the  problem  area  must  be 
manually  handled  to  solve  the  problem.  For  instance,  if  a 
batch  job  to  oompile  the  User  Interface  is  run  and  three  of  the 
files  do  not  compile  oorreotly.  the  problem  files  oould  be 
fixed  and  manually  compiled.  On  the  other  hand  if  an  include 
file  needed  changing  and  if  it  were  included  in  twenty  or 
thirty  files,  it  would  probably  be  easiest  to  fix  the  include 
file  and  then  redo  the  entire  compile  batch  job.  Backtracking 
is  often  required  during  the  release.  For  instance,  if  a  file 
in  the  NTH  services  needs  to  be  modified  to  solve  problems 
encountered  in  NTH  testing,  all  links  that  use  the  services 
must  be  redone.  Vhen  souroe  code  is  changed  to  solve  a  problem 
encountered  during  testing,  backtracking  must  be  done  as  far 
back  as  necessary  to  fix  anything  affeoted  by  the  change. 

4.2  Steps  for  a  VAX  Release 

1.  Log  onto  IXSS  and  set  your  default  to  [XXSS.OOM]. 

This  is  where  the  administrative  release  procedures 
are  looated. 

2 .  $  OVSTART 

This  procedure  can  be  run  only  at  the  beginning 
of  each  release.  It  uses  the  current  release  number 
from  [CKDB] RELMUM.DAT  to  create  a  release  specific 
directory  under  [CKDB]  for  the  release,  e.g. 
[CMDB.REL014]  for  release  1.4.  The  current 
MEVITEM.DAT  and  RETURN . DAT  are  copied  into  this 
directory.  CVTNEV . COM  is  oalled  to  update  CX.DAT  with 
all  nevitens  for  the  releases.  Other  newi teas  are 
retained  for  future  releases.  Vhen  new items  or 
returns  are  added  in  the  middle  of  the  release,  parts 
of  this  procedure  must  be  done  manually.  That  is. 
MEVITEM.DAT  and  RXTURN.DAT  are  oopied  into  the  release 
directory,  CVTNEV . COM  is  called,  and  RETURX.DAT  is 
deleted  from  [CKDB] . 

5.  If  any  items  in  CX.DAT  need  to  be  deleted  or  modified, 
run  UPDCX.COM  as  described  in  Chapter  3. 

4 .  S  9VSUBSTS 
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This  procedure  oreates  separate  files  is  the 
foraat  of  Cl. OAT  for  the  subsysteas.  These  files  are 
.TMP  files  and  are  put  in  the  release  specific 
directory,  [CMDB.RELOxx]  •  For  exaaple.  I PC. TMP  is  a 
sorted  list  of  the  I PC  subsystea. 

5.  Build  the  ooaaand  files  for  all  the  subsysteas: 

t  0VBLD00M  I PC 
$  OVBLDOOM  ERR 
S  OVBLDOOM  BTM 
$  WVBLDOOM  OOMM 
S  OVBLDOOM  UI 
S  OVBLDOOM  CDM 

All  coaaaad  files  to  release  the  subsysteas  are 
created.  The  files  created  are  put  into  the 
[CMDB.RELOxx]  directory  and  are  keyed  to  the  subsystea 
specified.  For  exaaple,  for  the  I PC  subsystea,  the 
files  created  are  the  following: 

-  GTIPC.COM  will  get  (retrieve)  I PC  source  code  froa 
SUSS  and  BUSS,  putting  it  in  IISS.  Include 
files  are  oopied  to  the  appropriate  IISS 
directories  (.SOURCELIB  for  . IMF  and  .IRC  files, 
and  .HLIB  for  .H  files). 

-  ILIPC.OOM  will  do  library  replaces  of  .IRC 
files  to  the  inolude  text  library, 

[ IISS . SOURCELIB] IISSCLIB . TLB . 

-  CLIPC.COM  will  do  the  coapiles. 

-  OLIPC.COM  will  do  object  library  replaces  and 
then  delete  the  .OBJ  files. 

-  LXIPC.COM  will  do  the  links. 


6.  $  RVCREGET 

This  oreates  a  file,  DOGET.COM,  that  will 
retrieve  the  souroe  oode  for  all  subsysteas. 

7.  Mow,  create  the  files  that  will  do  coapiles.  library 
replaoes,  and  links  for  the  subsysteas: 
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S  0VCREDO  ZPG 
$  OVGRKDO  ERR 
$  9VCRED0  VTM 
t  •VCREDO  COMM 
t  9VCRED0  UI 
$  •VCREDO  COM 

One  file  is  created  for  eaoh  subsystem  and  is  put 
into  the  [CMDB.RELOxx]  directory.  The  file  name  is 
keyed  to  the  subsystem  specified.  For  example, 
DOIPC.COM  is  oreated  for  the  I PC  subsystem. 

8.  $  0VDELALL 

This  procedure  calls  VDELETE  for  all  subsystems 
to  clean  out  all  files  from  the  IISS  directories.  It 
also  deletes  the  forms  library,  include  libraries,  and 
the  common  objeot  library,  IPCLIB.  All  libraries  are 
recreated  empty. 

9.  Set  your  default  to  [CMDB.RELOxx]  and  start  the  batch 
Job: 

S  submit/notify  DOGET.COM 

This  batch  job  will  pull  all  source  code  for  all 
subsystems  into  IISS  and  oopy  include  files  to  the 
inolude  libraries.  This  will  take  hours  to  oonplete. 
When  it  is  finished  a  batch  output  log  will  be 
printed.  Check  the  log  for  any  errors,  and  oorreot 
them  before  proceding. 

10.  Set  your  default  back  to  [IISS.COM]  to  do  the 
following : 

$  CVINIT 

This  procedure  does  some  of  the  ERRLOG  compiles 
and  library  replaoe&.  These  must  be  done  prior  to 
building  the  I PC  subsystem. 

11.  Mow  the  various  subsystems  oan  be  built.  Running 
VDORUX  creates  a  batch  Job  that  does  compiles,  library 
replaces,  and  links  for  a  given  subsystem.  The  batch 
Jobs  will  take  various  lengths  of  tine  depending  upon 
the  sise  of  the  subsystem.  These  runs  must  be  done  in 
the  following  order  beoause  of  links  that  depend  on 
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oo^ilations  of  other  subsystems: 

S  SET  DEF  [ I1SS.COM] 

S  •VDORUB  I PC 
$  9VD0RUV  ERR 
$  OVDORUR  MTM 
S  OVDORUV  COMM 
$  OVDORUV  UI 
$  OVDORUV  CDM 

A  batch  output  log  will  be  printed  at  the  end  of 
each  batch  job.  Check  it  for  errors.  Some  links  in 
the  UI  and  the  CDM  will  not  work  at  this  tine  because 
they  depend  upon  precompiled  nodules.  These  will  be 
done  manually  at  a  later  time. 

12.  The  forms  for  the  User  Interface  must  now  be  created 
by  running  the  stand-alone  version  of  FLAV  to  create 
all  the  .FD  files  from  the  .F0L  files.  The  .FDL  files 
are  located  in  [IISS.FD].  and  that  is  where  the  forms 
will  be  created.  Set  your  default  to  [IISS.FD]  and 
copy  the  flan  executable  to  there: 

S  copy  [IISS.UI .FLAM] FLAVSA.EXE  • 

You  need  to  reassign  the  IISSULIB  logical : 

I  assign  [IISS.FD]  IISSULIB 

Make  a  list  of  all  .FDL  files  in  the  directory. 
Run  FLANSA  once  for  each  .FDL  file.  When  you  run 
FLAVSA.  at  the  args  prompt  enter  the  name  of  the  .FDL 
file,  and  all  .FD  files  defined  in  that  file  will  be 
created . 

13.  Mow  the  release  is  basically  built,  and  testing  and 
precompiling  need  to  be  done.  (Testing  can  actually 
be  started  after  the  MTM  has  been  built,  and  other 
subsystems  can  be  tested  as  they  are  built.)  The 
testing  is  done  in  the  TIISS  account,  tinder 

[TIISS . TESTXX] .  After  the  directories  in  TIISS  have 
been  cleaned  out,  log  onto  IISS,  set  your  default  to 
[IXSS.OOM],  and  move  the  necessary  files  to  TIISS: 

$  OMOVEALL 

14.  Directions  for  integration  testing  are  found  in  other 
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manuals.  (See  IISS  Documentat i on  Description, 

CMB620 100000,  for  a  list  of  the  documents.)  Normally 
the  IPCs,  ERRLOG,  and  COMM  are  tested  first.  Then  the 
MTM  tests  are  run.  Then  the  UI  tests  that  are  not 
dependent  upon  a  precompiled  module  are  run.  Then,  at 
the  beginning  of  CDM  testing,  the  preoompiles  needed 
for  the  rest  of  the  release  build  are  done. 
Documentation  for  this  is  provided  for  each  release  by 
subcontractors  responsible  for  the  subsystems 
requiring  precompilation.  Most  information  on  this  is 
contained  in  an  attachment  to  the  CDMP  Test  Case 
Report  Documentation,  called  Define/Construct  HDDL. 

15.  When  all  precomp nations  needed  to  finish  building 
IISS  have  been  completed,  the  .THP  files  created 
during  precompilation  must  be  moved  batch  to  IISS  for 
the  build.  Move  these  files  to  [ IISS. CDM. HDDL] . 

16.  Log  batch  onto  IISS  and  set  your  default  to  [.CDM]. 

Mow  execute  the  procedures  BLDMDDL.COM  atnd  CRELLST.COM 
as  described  in  the  manual,  Define/Construct  HDDL,  to 
create  the  procedures  to  do  the  needed  compiles  atnd 
linhs.  After  you  have  run  the  compile  atnd  1  inh 
procedures,  you  cam  do  the  linhs  that  failed  earlier 
due  to  references  to  precompiled  modules.  Mow  IISS  is 
entirely  built,  atnd  testing  of  the  UI  atnd  the  CDM  catn 
be  completed. 

17.  When  testing  is  deemed  complete  atnd  all  required 
ohanges  have  been  made  to  SCM,  IISS,  atnd 
[CMDB.RELOxx] ,  IISS  can  be  prepared  for  mathing  the 
release  tape.  Directories,  such  as  [IISS. MTM. ..  ]  atnd 
[IISS.UI...]  should  be  purged,  atnd  .LIS  files  atnd  .LOG 
files  should  be  deleted. 

18.  The  .BUILD  directory  must  be  made  current.  The 
following  procedures  are  done  manually: 

-  Copy  the  CL...,  OL...,  atnd  LK...  files  over  into 
[IISS. BUILD]  from  [CMDB.RELOxx]. 

-  Copy  the  compile  atnd  library  replace  oommatnd  files 
that  were  created  in  [IISS. CDM]  for  the 
precompiled  modules  together  into 

1 IISS . BUILD]CMPMDDL . COM . 

-  Copy  the  1 inh  file  that  was  created  in  [IISS. CDM] 
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for  the  precompiled  aodules  into 
t I I SS . BUILD] LNKLST . COM . 

-  Check  all  coaaand  files  in  [IIS8. BUILD] ,  such  as 
NOVERtm.COM,  to  see  if  they  are  current 
correct . 

-  Now  purge  the  files  in  [IISS. BUILD] . 


19.  The  [IISS. ORACLE]  directory  needs  to  be  updated  for 
the  new  release.  Tour  ORACLE  database  adainistrator 
should  provide  you  with  current  . BCK  and  .VEW  files 
froa  an  export  of  the  database,  and  he  should  verify 
the  current  correctness  of  ORAUSER.COM  mxi 
ORAUSERL.COM. 

20.  The  [IISS.RUNAREA]  directory  should  contain  only  two 
files.  SYSGEH.DAT  and  the  file.  The  file 
should  oontain: 

args: 

args: 

21.  The  release  tape  can  now  be  aade.  Log  onto  IISS  on 
the  hard  copy  terainal  and  aount  the  tape.  Then 
initialize  the  tape: 

%  INIT/DENS-1600  MT:  IISS 
$  MOUNT/FOR  MT: 

Now  create  the  release  tape: 

BACKUP/VER/LIST-TP.LIS  IISS_CM: [IISS . . .) 

/EXCLUDE-C * .OBJ ,» .OLB . EXE . * .MAI , [ IISS .COM] * .» . 
[IISS. UTILITY]* .* .[IISS.MCMM]* .*)  MT: IISS. BCK 

When  the  tape  is  finished,  print  the  listing: 

S  PRINT  TP. LIS 

22.  The  Installation  Guide  COM  620124001)  should  be 
updated  to  be  provided  with  the  release  tape. 

25.  It  is  recoaaended  that  a  trial  build  be  done  with 
the  tape  on  a  VAX  with  the  appropriate  hardware 
and  software.  If  any  probleas  are  encountered  in 
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34. 


the  build,  the  appropriate  corrections  may  be  made 
in  [2X88]  prior  to  the  making  of  another  release 
tape.  Ideally  this  procedure  is  repeated  as 
necessary  until  a  tested  final  version  of  the  tape 
encounters  no  problems. 

Since  the  release  is  eonplete,  the  release  number 
should  be  updated  la  KXUrUH.DAT  by  entering  the 
following  (with  your  default  set  to  [IISS.OOM]): 

9  8VX8D  rein 

where  rein  is  the  next  release  number  (e.g.  2.1) 
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SECTION  5 

IBM  RELEASE  PROCEDURES 


5-1  General  Description 


IBM  release  tapes  are  created  from  an  IBM  release  account 
on  the  VAX,  IISSIBM.  The  directory  structure  of  IISSIBM  is 
similar  to  that  of  IISS,  the  VAX  release  directory.  Code  that 
is  used  for  building  the  release  on  an  IBM  is  located  in 
[ IISSIBM. BUILD] ,  and  release  procedures  that  are  used  for 
creating  the  release  tape  from  the  VAX  are  located  in 
[IISSIBM.COM], 

The  IBM  release  includes  the  following: 

-  VAX  release  procedures  are  used  as  needed  to  update 
Cl. DAT  and  create  the  .TMP  files  that  are  the  sorted 
lists  for  each  subsystem. 

-  The  IBM  release  directory  is  cleaned  up  in  preparation 
for  the  new  release. 

-  Command  files  for  the  release  are  built,  one  subsystem 
at  a  time. 

Source  code  is  moved  into  IISSIBM. 

JCL  files  to  do  compiles  and  links  on  the  IBM  are 
moved  to  the  [.BUILD]  directory. 

A  directory  listing  of  all  files  to  go  on  the  tape  is 
created . 

The  release  tape  is  created. 

-  The  contents  of  the  tape  must  be  loaded  onto  an  IBM  to 
test  the  build  procedure  and  to  test  the  IBM  version 
of  IISS. 

5.2  Steps  for  an  IBM  Release 

1.  Do  steps  1,2,3,  and  4  of  the  VAX  release  procedures 

(Section  4.2)  as  needed,  unless  they  have  already  been 
done  for  the  VAX  release. 


5-1 


CMA620 124000 
1  November  1985 


2.  Log  onto  IXSSIBM  and  set  your  default  to 

[IISSXBM.COM] .  To  do  the  neoessary  prerelease 
cleanup,  run  the  following: 

$  0IDELALL 

5.  Build  the  oo— and  files  to  release  the  subsystems: 

$  ©IBLDGOM  I PC 
$  6IBLDC0M  NTH 
$  ©IBLDCOM  COMM 
$  ©IBLDCOM  UI 
$  ©IBLDCOM  CDM 
S  ©IBLDCOM  CICS 

4.  Pull  the  source  code  into  IISSIBM: 

$  SUBMIT/NOTIFY  GTIPCxx 
$  SUBMIT/NOTIFY  GTNTMxx 
$  SUBMIT/NOTIFY  GTCOMMxx 
$  SUBMIT/NOTIFY  GTUIXX 
$  SUBMIT/MOTIFY  GTCDMxx 
%  SUBMIT/ NOTIFY  GTCICSxx 

where  xx  is  the  release  number  (25  for  Release  2.5). 
Check  the  logs  that  are  automatically  printed  at  the 
end  of  the  batch  Jobs.  These  batoh  Jobs  may  be  run 
concurrently. 

5.  Move  all  the  oompile  and  link  files  to  the  [.BUILD] 
directory: 

$  copy  CL* .JCL  [IISSIBM. BUILD]* 

$  copy  LK* .JCL  [IISSIBM. BUILD]* 

6.  While  your  default  is  still  set  to  [IISSIBM.COM],  it 
is  necessary  to  create  the  log  datasets: 

$  6IBLDL0G 

7.  The  tape  can  now  be  created.  Log  onto  IISSIBM  on  the 
hard  oopy  terminal  and  set  your  default  to 
[IISSIBM.COM].  Mount  a  tape  and  then  start  creating 
it: 

$  OCRTTAPE 
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Vhen  the  tape  is  finished,  print  the  listing: 

$  PRINT  TAPE . HST 

8.  The  Installation  Guide  COM  620124002)  should  he 
updated  to  be  provided  with  the  release  tape. 

Building  and  testing  anst  be  done  on  the  IBM.  and  any 
needed  corrections  nust  be  >ade  on  the  VAX  prior  to 
aaking  a  new  tape. 
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SECTION  6 

MANUAL  SCM  PROCEDURES 


If  everything  in  a.  relea.se  were  to  work  perfectly  the 
first  tine,  it  would  only  be  necessary  to  nse  the  autonated 
procedures.  However  this  is  rarely  the  case,  so  that  knowing 
how  to  do  parts  of  the  procedures  Manually  is  a  necessity. 

When  a  file  needs  to  be  changed  for  any  reason  after  the 
release  is  started,  the  new  version  can  be  pulled  into  IXSS. 

The  file  nust  be  changed  in  Configuration  Managenent  by  using 
the  user  functions  CHECKOUT  and  RETURN.  This  is  noraally  the 
responsibility  of  the  developer  in  charge  of  the  particular 
subsysten.  Then  you  nust  log  onto  XISS  and  set  your  default  to 
the  directory  where  the  changed  file  resides.  Delete  the  old 
file.  Then  bring  in  the  new  version  with  the  following  SCCS 
oonnand: 


$  GET  -Rn  IISS_CM-/SIISS/subsy6/Bubdir/SXf ilenane. extension 

Fill  in  the  appropriate  values  for  subsysten,  subdirectory, 
f ilenane.  extension,  and  n  (the  SCCS  internal  nunber,  e.g.  10 
for  Release  2.0,  15  for  Release  2.5,  or  29  for  Release  5.9). 

When  a  new  file  has  been  pulled  in,  all  needed  oonpiles, 
library  replaoes,  and  links  nust  be  performed  to  accommodate 
the  change  into  the  release.  These  are  aoconplished  with 
standard  VMS  procedures.  Refer  to  the  appropriate  Product 
Specif ication(s)  for  infornation  on  what  will  be  affected  by 
the  changed  nodule  or  include  file.  The  fornat  of  sone 
connonly  used  procedures  is  as  follows: 

%  COBOL/ ANSI /NOLIST  f ilenane 

$  FORTRAN/NOLIST  f ilenane 

$  CCX  f ilenane 

t  LIBRARY/REPLACE  xOLB.OLB  f ilenane. OBJ 

where  x  is  the  first  4  characters  of  the  directory, 
t  COPY  f ilenane. H  (XXSS.HLXB]* 

$  COPY  filename. INC  [XXS8.S0URCELXB] * 
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$  LIBRARY /REPLACE/TEXT  II88GLIB  filename. IRC 

$  COPT  filename. IMF  tiISS . SOURCELIB] 

Deletes  and  purges  should  be  done  throughout  as  needed  to 
keep  I  IBS  current  and  clean. 
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